SpecGen: AI-Based Reverse Engineering Framework of SDLC Document Generation

Abstract

The complexity of modern software systems has grown, and documentation has not always kept up. It is complete, old-fashioned or absent in most instances. Practically, this gives rise to a number of issues, such as the onboarding of new developers becoming slower, maintenance being more painful, and a technical debt accruing over time. SpecGen aims to fill this software documentation gap. It is a reverse engineering platform that is AI-driven and accepts a repository on GitHub as input and produces a full set of Software Development Life Cycle (SDLC) documentation. These comprise requirements specifications, architecture diagrams, API catalogs, security reports, and test artifacts. The idea is to generate all this automatically, without developers having to write or maintain documentation. Besides the static analysis, SpecGen has a number of built-in capabilities that provide additional functionality.

Introduction

The text describes SpecGen, a system designed to solve the long-standing problem of poor and outdated software documentation in real-world development projects. It highlights that maintaining SDLC documentation is difficult because codebases change frequently, leading to incomplete onboarding, inefficiency, and outdated architectural knowledge.

To address this, SpecGen proposes an AI-driven automated documentation system that generates accurate SDLC artifacts directly from source code. Its key idea is to reduce manual effort by extracting structural metadata from repositories and using it to generate reliable documentation with minimal hallucination.

The system is built as a multi-layer architecture:

• A React-based frontend for user interaction and visualization
• A Node.js/Express backend for repository validation and analysis
• A metadata extraction engine using static code analysis
• An AI layer for generating documentation and chatbot responses

SpecGen follows a step-by-step pipeline that includes:

1. Repository validation via GitHub
2. Static code analysis and metadata extraction
3. Architecture and diagram generation (HLD/LLD)
4. AI-based SDLC documentation generation
5. A code-aware chatbot using Retrieval-Augmented Generation (RAG)
6. Final documentation assembly and export

The system also introduces features like:

• Automated syncing via GitHub webhooks
• Versioning and diff tracking of documentation changes
• Automatic API endpoint extraction and OpenAPI export
• A RAG-powered chatbot that retrieves relevant code before answering queries

Conclusion

The problem of appropriate documentation in software engineering is not likely to work itself out. It is a structural problem: documentation is hard to write, hard to maintain and in fastpaced development groups it is usually low on the priority list. It provides the creation of comprehensive software documentation that requires only a small amount of manual intervention by integrating validation-first repository analysis, multi-diagram generation, AI based SDLC artifact synthesis, a code aware RAG chatbot, automated API catalog generation, continuous webhook-based synchronization, and a Quality Gates scoring system into a single platform. The design decisions all over SpecGen are indicative of a single ideology: automation is supposed to be transparent and not opaque. Every AI generated product is based on vali-dated structural metadata, and intermediate products are published to view. To addition, each score is subdivided into meaningful dimensions, which the developers can then not only act upon. This methodology will make the human remains be actively involved in the process- not merely going through the outputs, but knowing what is being analyzed, how it is processed and the reason why the final documentation takes its final shape.

References

[1] A. Kuhn, D. Erni, and O. Nierstrasz, \"Software Cartography: Thematic Software [2] Visualization with Consistent Layout,\" Journal of Software Maintenance and Evolution: Research and Practice, vol. 22, no. 3, pp. 191–210, 2010. [3] S. Brown, \"The C4 Model for Software Architecture,\" IEEE Software, vol. 35, no. 4, pp. 85–90, 2018. [4] P. Lommerse, F. Frissen, and J. van Wijk, \"SourceTrail: Interactive [5] Exploration of Design Flaws in Software Systems,\" in Proc. IEEE VISSOFT, 2019, pp. 1–9. [6] C.-A. Staicu and M. Pradel, \"Detecting and Visualizing JavaScript Module Dependencies,\" arXiv preprint, 2021. [7] R. Li, P. Liang, M. Soliman, and P. Avgeriou, \"Understanding Software Architecture Erosion: A Systematic Mapping Study,\" Journal of Systems and Software, vol. 181, pp. 111041, 2021. [8] W. Sun, Y. Miao, Y. Li, H. Zhang, C. Fang, Y. Liu, G. Deng, Y. Liu, and Z. Chen, \"Source Code Summarization in the Era of Large Language Models,\" arXiv preprint arXiv:2407.07959, 2024. [9] S. Ducasse and D. Pollet, \"Software Architecture Reconstruction: A Process-Oriented Taxonomy,\" IEEE Transactions on Software Engineering, vol. 35, no. 4, pp. 573–591, 2009. [10] M. Lanza and S. Ducasse, \"Polymetric Views — A Lightweight Visual Approach to Reverse Engineering,\" IEEE Transactions on Software [11] Engineering, vol. 29, no. 9, pp. 782– 795, 2003. [12] P. Lewis et al., \"Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,\" in Advances in Neural Information Processing Systems (NeurIPS), 2020. [13] D. Binkley and M. Harman, \"A Survey of Empirical Results on Program Comprehension,\" Advances in Computers, vol. 62, pp. 105–184, 2004.

Copyright

Copyright © 2026 Dr. Manimala S, Shravya S Mogaveera, Thejas C, Vishruth G, Mallika V. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.